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ABSTRACT 



A system for facilitating commercial transactions, between 
a plurality of customers and at least one supplier of items 
over a computer driven network capable of providing com- . * i 
munications between the supplier and at least one customer ctllCK S*T& 
site associated with each customer. Each site includes an 
associated display and an input device through which the 
customer can input information into the system. At least one 
supplier is presented on the display for selection by the 
customer using the input device. Similarly items from a 
supplier can be displayed for the customer to observe. 
Associated with a supplier of such items is an item database 
including information on presented items. Pricing subsystem 
receives information from the item database to determine the 
cost associated with a presented item. In addition a customs' 
information database stores information r elating to the cus- 
tomer . Associated with each customer is a customer moni- 
toring object far each customer. The customer monitoring 
object is created by referencing information, relating to that 
customer, which had been stored in the customer informa- 
tion database and when the customer selects a supplier. The 
customer monitoring object is configured to operate by 
responding to customer enquiries regarding a presented item - - « 
by retrieving information r elating to the item and presenting^ CMAX] . 
the information to the customer, re ceiving a customer's —Y't\Y K (LJ&ViwC&+ 
selection of a presented item; receiving customer *T>rCfc&t^'te * 
communications, indicating a desire to receive the item; and "* » CAAGA' 




passing a communication to initiate the delivery of the item 
to the customer. 

49 Claims, 15 Drawing Sheets 
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COMPUTER SYSTEM AND METHOD FOR $uch as simultaneously offering a multitude of price 

ELECTRONIC COMMERCE discounts. pertAntiino targeted advertisin g, or collecting 

s ales feedback. 

BACKGROUND Another company, Open Market, is developing a similar 
1. Technical Field 5 electronic catalog system consisting of a HypetText Markup 
This invention relates to a system for conducting inter- Language (HTML) authoring tool (called Stccebuflder), and 
active electronic commerce among a plurality of a server (called Webserver) connected to an integrated 
participants, and more particularly to a computer architec- back-end commerce system (called TYansactionlink). This 
ture comprising a family of distributed, interface-compatible system appears to share similar characteristics and disad- 
commerce subsystems, where each electronic store operator 10 vantages as the Netscape system, 
selects a particular combination of subsystem implementa- Thus, existing computer architectures for on-line elec- 
tions to meet store specific operating needs. tronic commerce are service provider-specific architectures 
2 Background that are platform-limited (the Internet) and require confor- 

tt is desirable to provide a system and method far con- 15 to a P 9 *™ ^ «P cdflcd 

ducting commerce via an electronic means, such as a com- 15 ^mentations Such dosed architectures may ^eatly 

puter network, cable television network, or direct dial Umit their expandability or widesr^ acceptance JBven if 

modem. Previous attempts to provide electronic commerce widespread acceptance occurs, this is likely to be defeated 

subsystems have been custom tailored to an individual over a number of com^^ 

commerce offering, and have not been adaptable to be able M crabmty my force customers to log on to different archi- 
to provide a versatile system capable of supporting a wide " f°r Afferent transactions or force vendors to main- 
range of providers of goods and services. .^valent operations on different aremtcctures. Such 
* - . . . . , architectures are aimed at a customer-retailer level of 
To meet this need, several companies have developed commacc ^ CTcn ^ mat lcvcl> ^ ^ not support me 
computer archntectures f or onbne electronic catalog sales intra . leve , competition (eg., Compuserve's electronic store- 
using, for example, the Internet as a traosport mechanism to M versusAinerica Onlinc^s customer electronic 
transmit datarepresenttng purchase requests between a 6torefront) ^ characterizes real-world commerce. The 
propnetary browser and server product pair. architectures are also too flat to support the complex inter- 
For example, Netscape Communications uses its , evel (e . g; manufacturer-distributor-retailer 
Navigator/Netsite World Wide Web (WWW) browser/server rclationships ) that characterize real-world commerce, 
pair. A buyer uses a Navigator to select a seller's Netsite 30 F i n »llv th« architectures do not accommodate the marketing 
server (sort of an electronic storefront), which is in turn actjrttjcTneces Mry for customer generation. Overall, the 
coupled to standard application servers (back-end existing aiciuieckres may be thought of as electronic cata- 
subsystems), e.g., a credit server or a member server for , architectures rafter than general electronic commerce 
collecting demographic information on customers. These architectures, 
servers contain the business rules denned by the seller, e.g., 35 

what credit cards are accepted and what customer informa- OBJECTS OF THE INVENTION 

tion " racked during each sale. Some of these servers are fi { therefore, an object of the invention to provide a 
connected to external, thffd-party services, e.g., the credit ^ fa facflitatin commercial transactions over a corn- 
server to an external credit card processing .network or the ' ^0^^ 0 f providing communications 
member server to an external demographics processing « between a supplier and at least one customer site associated 
module. The actual applications e.g., on-line publishing or with Mch c ^, omer ^ including an input means and a 
catalog sales, are represented as extensions of the applica- disolav 

tion servers. Equivalently, the application servers are said to * . , ., . , . . .. 

be instantiated in the applicatfons. The net result of this , tt 18 f fwtka rf mv ™ to P 1 ™^ 

approach is that the busies* rules (from the application 45 Moronic commerce computer architecture which can 

^IL?* 0n ^ ; t. v „r j • a * Tv. r ,* *u commerce implementations currently being used for physi- 

This model has a number of disadvantages. First, the - __™\ tf ^ , ;tt1o ^^fi,,^-' 

. , . . , • Z 1 7 *u cal commerce witn little modoncation. 

system is limited to a single communications platform, the ^ , , ^ _ . . _ , 
Internet This is rxrau^ 50 . of ^ mvenU011 ^provide actual 
to implement the model is dependent on the Transmission implementations of some commerce subsystems where 
Control ProtocoVIntemet Protocol (TCP/IP) used in the existing commerce subsystems used for physical coinmerce 
Internet Hie model has no provisions to allow communi- marketing subsystems) are not readfly extendible to 
cations to platforms not using TCP/IP, for example, inter- electronic coinmerce or where those subsystems do not 
active TV. Second, in the Netscape model, business flex- 55 currenfl y ed- 
ibility is low because of the mtenningling of business rules It is still another object of the invention to provide an 
and application logic. It is more difficult to modify a portion electronic commerce computer architecture, comprising a 
of the resulting monolithic application than it would be to family of interconnected commerce subsystems, where 
modify a portion of a smaller module of a modular appli- changes can be made to one subsystem without affecting the 
cation. This may have negative impacts on reliability and 60 otner subsystems. 

availability, because in certain cases it may be necessary to It is yet another object of the invention to provide an 

shut down the system to make changes mat must be syn- electronic commerce system, comprising a family of inter- 

chronlzed between two or more components. Third, such connected commerce subsystems, where the subsystems can 

electronic catal ogs support product display and secure pay - be distributed across many different platforms and networks. 

ipLill [iiunaAimi. [juLnot the marketing acti ve m nft^fritq 65 Yet a further object of the invention is to provide an 

induce customers into reading the electronic catalogs. Thus. electronic commerce system which closely replicates com- 

t here are no counterparts for chv^ ^i rnrnmerre yftyi^es mercial transactions in everyday life. As such it is another 
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object of the invention to provide for an electronic assistant easterner payment for the desired item The payment handler 

to assist a customer during interactions with the system to is responsive to communications from the customer moni- 

facilitate electronic commercial transactions. toting object. Also, the customer monitoring object is con- 

SUMMARY OF THE INVENTION figured to confirm to the customer that the order for the item 
, , , -5 has been successfully processed. 

Briefly, therefore, to invenbon provides for a systemfor ^ tcm inclndes a ™„ t va Kdation 

cilitatinK commercial transactions, between a plurality of , ' \ } j"""*"^ « F ' . 

^" customers and at least one supplier of items. Tie commer- \ mea f of *? customer momtonng object 

transactions occur over a computer driven network tccei ™ *e mformimon related to Re forms of payment 

» r. , ... . ^ ^7 . «. _ available to the customer and presents the customer with a 

capable of providing communications between the supplier tn ~\ * " - ^ \ ^ ^ « 

andatleast^ecustomersiteassodatedwimeacAcus^er. 10 ^^^^f f^^f^^f 

Each site includes an associated display such as a personal * &st secnn ? ^ rek ^ ^ectedform £ M™"* 

ciui Mic uiuuu»<^ ,.Zt;i' r ~~* „ .J^ .„„» Thereupon, the first security code is validated by compan- 

coiimuter, set-top box, atouc^ V ^ ^ > 

telephone or any other device capable of reproducing to ^J^f^" f<x me ^ ^ tf me 

audio or video information to a human bang. Each site monuoimg oojecu rayracm i« iuc ™ u mi 
typically also includes an input means such as a keyboard or 15 &st security code is validated. 

computer "mouse" through which the customer can input The system of the invention also allows for incentives to 
information into the system. encourage the customer to complete a transactions. Such 

The system of the invention facilitates the presentation of incentives could mctade cost reductions such as price dis- 
at least one supplier on the display for selection by Ihe „ ^formation regarding these wst reduces* stored 

customer using die input mean S P Similarly items from a 20 within the system, often in association with specific irfor- 
supplier can be displayed for the customer to observe. ***** to the customer and also associated with a 

rr . , _ ^ - , * . . .. _ « . , „ suDolier s items. The pricing means receives relevant parts 

Associated with a supplier of such items is an item database au^i iu,u». mv pivui B * 
deluding iirformatioV on presented items. Pricing means <>f the cost reduction iiifannation to calculate the cost oHhe 
receives iiuWrionfrom 25 associated item Typically, the customer monitoring object is 

^ass^ated wim apre^nteditern. In addition a customer 25 ^?^?J'^V|^ , ^^^ e ^^:^^^ ^m^ta Ae^^ me^^^" 
information database stores information relating to the cus- cate ** reductl0D formation to the pricing means, 
tomer. The system also comprises means for creating a The customer monitoring object is also configured to 
customer monitoring object for each customer. confirm to the customer mat the order for the item has been 

The customer monitoring object is created by referencing ^ successfully processed 
information, relating to mat customer, which had been stored The system of the invention further comprises supplier 
in the customer information database and when the customer control means for receiving input, from a supplier, for 
selects a supplier. The customer monitoring object is con- changing the cost reduction information. One way of doing 
figured to operate by responding to customer enquiries, this is by having the supplier control means receive an input, 
communicated through the input means, regarding a pre- 3S from a supplier, at a first time defining changes to the cost 
sented item by accessing the item database to retrieve reduction information for a second time later than the first 
information relating to said item and to present said infer- time. This enables a supplier to define in advance both the 
mation to the customer by means of the display; receiving a timing and the magnitude of the discount that is applied, 
customer's selection of a presented item through the input The customer monitoring means can be "short lived" and 
means; <x>mmuni eating with the pricing means to cause the ^ cease to operate on the termination of a transaction. Trans- 
cost of the item to be determined; presenting the cost to the action termination is generally effected by a command from 
customer by means of the display; receiving customer the customer. Alteratively, when the customer terminates 
communications, through the input means, indicating a interaction with the supplier, the customer monitoring object 
desire to receive the item; and passing a delivery initiation could temporarily cease to operate. In this case, information 
communication to initiate the delivery of the item to the 45 regarding at least the interaction is stored for retrieval at a 
customer. subsequent time at which the customer interacts with the 

The customer monitoring object can also be configured to supplier. At that time the customer monitoring object re corn- 
maintain a Kst of selected items and to present the customer mences operation without being recreated, 
with a total cost of all selected items for approval before the The system further comprising a means for accessing the 
customer monitoring object passes the delivery initiation so customer information database and for creating a participant 
cttinrnunication. As part of this function, the customer program object The participant program object includes 
monitoring object could be configured to present the cus- customer specific information retrieved from the infonna- 
tomer with an opportunity to deselect an item whereupon the tion database. The participant program object is in commu- 
customer monitoring object causes the total cost of the ni cation with and electronically represents the customer to 
remaining selected items to be redetermined and presented 55 the customer monitoring object The participant program 
anew to the customer. object is created at the time an interaction between the 

The system further comprises an order fulfillment initia- customer and the system commences. It preferably includes 
tion system, responsive to the delivery initiation communi- information related to forms of payment available to the 
cation from the customer monitoring object, for initiating customer. 

proceedings to cause the item desired by the customer 60 The system may also comprise an observation system for 
delivered to the customer. To enable this, it is preferable that receiving and maintaining customer interaction information 
the order fulfillment system include an interface with a relating to at least one customer's communications over the 
shipping facility for facilitating the shipping of the desired computer driven network. Preferably, the supplier control 
item to the customer. Typically the shipping facility will be means is in communication with the observation subsystem 
an existing facility known in the art 65 and receives customer interaction information far display to 

To arrange payment for any transactions, the system of the the supplier. The supplier control can include an information 
mvention furmcx comprises a payment handler for initiating processor for processing received customer interaction 



03/30/2004, EAST Version: 1.4.1 



5,710,887 

5 6 

information; and means for selectively displaying at least a downloaded to a viewer's multimedia display, as well as 

part of the processed customer interaction information to the deliveryless transactions such as selling stock shares held in 

supplier. a central repository. 

Additional features of the invention will become apparent The Electronic Mall 

upon examination of the description which follows partial- 5 It is useful conceptually to think of electronic commerce 

larly with reference to the accompanying drawings. as exemplified by an electronic mall comprising a collection 

of suppliers of items such as goods or services, such as 

DESCRIPTION OF THE DRAWINGS electronic stores, analogous to a physical mall comprising a 

collection of physical stores. In this example, each commer- 

In the accompanying drawings: 10 cial transaction constitutes a sale from an electronic store to 

FIG. 1 is a schematic representation of an electronic mall a customer of the electronic store, where a customer can be 

exemplifying the electronic commerce architecture of mis any participant in the electronic commerce architecture, 

invention. It should be noted, however, that electronic malls and 

FIG. 2 schematically depicts an embodiment of the inven- stores are of vastly broader scope than their physical coun- 

tion configured to support transaction processing. 15 terparts because the electronic mall can contain electronic 

FIG. 3 depicts a compartment level view of the system of stores composed of independent functional subsystems 

pjQ 2 located at various platforms and networks in an electronic 

FIG." 4 depicts a compartment level view of the system, h ^ s P ace ^compassing the Internet, mteracdye TV, exist- 

. : ' ",7 wnTrr i il f c* *T; ing legacy systems, and many other electronic venues. 

similar to that id FIG. 3 but with a plurality of Storefront ^ * *u i *- • * - + • u - i 

^ * 20 Moreover, the electronic store is not limited in geographical 

* s ms ' reach (e.g., a national stare is possible), in goods sold (e.g., 

FIG. 5 schematically represents an outline transaction physical products, digital information, and deliveryless 

using the system of the invention. transactional services are all possible), or to customer- 

FIG. 6 depicts the completion of the online transaction of merchant relationships (e.g., an entire distribution chain 

FIG. 5. 25 from manufacturer to consumer can be accommodated). 

FIG. 7 depicts the process by which a customer selects FIG. 1 shows an electronic mall, generally indicated as 

items for purchase in an online transaction of FIG. 5. 10, that exemplifies the electronic commerce architecture 

FIG. 8 depicts the completion of the online transaction in provided by this invention. A Customer 12 enters the elec- 

the commerce system illustrated in FIGS. 5 to 7. *onic mall via a user interface 13, where the customer is 

nG.8AdepictsmestepsofnG.8performedbytheSales 30 £ cs ?f d . a ^ '« ^^y^ Electronic Stcrefronts 

iiu.«^iv»uivi,^vi»ivj l y j 14. The user interface 13 may be a personal computer, 

Representative frogram Object ^ a ^ a ^ tofle 

FIG. 8B depicts the steps of FIG. 8 performed by the or ^ otner ^vice capaD i e 0 f reproducing to audio or video 

Payment Handler Interface and Participant Program Object information to a human being. It typically includes an input 

FIG. 9 depicts one example of the use of a User Interface 35 means such as a keyboard or computer "mouse 1 ' through 

to select the preferred payment method. which the computer can input information into the system. 

FIG. 10 schematically illustrates the creation of incentives The customer enters a particular electronic store by select- 
in the system of the invention. ing its Electronic Storefront 14, e.g., by clicking on an icon 

FIG. U depicts a Pricing Rule Structure. wifc a conventional selection or input device such as a 

™~. »^ *i r ^ . , 4 , 40 mouse/curs er device touchpad. As the customer enters the 

FIG. 12 depicts the operation of a Dashboard Client to " T . . ~ v. i_ 1 , , 

• j * j TT «. ^ . store, Internal Commerce Subsystems 16 are invoked by 

maintain the data needed to operate a storefront _, . _ _ ^ . ' A . , . ^ » 

liuuutoui ui* u«a «w w v^au, 4 . Electronic Storefront 14 to represent the store's interactions 

FIG. 12A depicts one view of the Dashboard Client as it ^ customer, 

appears to a storefront operator. A s the customer decides what items to purchase, External 

FIG. 12B depicts a second view of the Dashboard Client 45 Commerce Subsystems 18 may be invoked to complete the 

as it appears to a storefront operator. transaction. For example, VESA's credit card network may 

FIG. 13 is a flowchart that depicts the operation of the be used for payment followed by FedEx's Powership ship- 

Mcing Engine applying Coupons according to the inven- ping management software for shipping, 

tion. In the meantime, the store's management can use a Store 

FIG. 14 schematically illustrates the registration process 50 Management Dashboard 20 to interface and control the 

of the Observations Subsystem. Commerce Subsystems 16 and 18; for example, to establish 

™ 1C . „, llcfMfrM tUt > mnt „«ti« M tj rt n in-store sales as incentives to the customer. 

™\ *"* U0tl&c&tl0a The Internal Commerce Subsystems 16, External Corn- 
process of the Observations Subsystem. merce subsystems 18, Electronic Storefront 14, and Store 

DESCRIPTION OF EMBODIMENTS 53 Management Dashboards 20 interact with each other 

through Internal Commerce Subsystems Interfaces 24 and 

L Overview External Commerce Subsystems Interfaces 22. 

This invention relates to a computer architecture for n. Subsystem Overview 

on-line commerce which defines an electronic infrastructure Following from the above it may be apparent that each 

to enable a full range of commercial transactions analogous go electronic store in .an electronic mall must be able to manage 

to those occurring in physical commerce. customer information, support targeted advertising, perform 

It is evident that a participant in electronic commerce market research, execute on-line marketing programs like 

might include a manufacturer of goods selling to a discount pricing, and ensure secure and reliable order and 

distributor, a distributor buying from a manufacturer and financial transaction processes, all within the context of its 

selling to a retailer, or a retailer buying from a distributor 65 own operating style. 

and selling to a consumer. The items sold need not be limited This invention provides such flexibility at the individual 

to goods, but could also include services such as videos store level while supporting simultaneous transactions 
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among a plurality of electronic stores, by defining a family tion provides only standardized interfaces to the commerce 
of elementary Commerce Subsystems 16 and 18 necessary subsystems, while in the latter, the invention can provide 
to support the various elements of electronic commerce, and actual subsystem implementations as well as the interfaces, 
allowing each store to select a particular combination of This distinction provides great openness and flexibility by 
subsystems interconnected in a particular pattern to suit its 5 allowing electronic commerce participants to select External 
particular operating style. Commerce Subsystems from a variety of currently existing 

It may be useful to think of these Commerce Subsystems business subsystems, while providing Internal Commerce 
as "distributed objects" accessible to various of the stores Subsystems for those Commerce Subsystems where cur- 
and indeed to multiple stores, at the same time. Although not rently existing business subsystems either do not exist or are 
illustrated in FIG. 1, these Commerce Subsystems include: 10 unadaptable from physical to electronic commerce. In either 
an Incentives Subsystem; an Observations Subsystem; an case, the architecture provides standardized interfaces 
Order Fulfillment Subsystem; a Participant Subsystem; a through which Commerce Subsystem implementations corn- 
Payment Handler; a Pricing Subsystem; a Product Database; muni cat e with the architecture. Thus, the distinction 
a Promotions Subsystem; a Sales Representative Subsystem; between External and Internal is somewhat arbitrary, as it 
a Redemption Registry; a Security Subsystem; a Shipping is reflects the commercial availability of existing subsystem 
Subsystem; and a Tax Subsystem. technologies rather than any fundamental difference 

The Customer Accounts Subsystem is a store-specific between the two subsystem categories, 
repository which holds information on that store's custom- Thus, each of the Internal and External Commerce Sub- 
ers* demographics and payment habits. likewise, the Incen- systems is a self-contained, independent module connected 
tives Subsystem is a marketing module which allows stores 20 into the architecture through a standardized interface. The 
to establish discount programs such as in-store sales, modules as a whole can be arranged in any combination for 
coupon-based discounts, frequent buyer programs, and any particular store. Note that the above categorization of 
quantity discount cards. Commerce Subsystems as Internal or External is exemplary, 

Similarly, the Participant Subsystem is a shared repository not mandatory. That is, a particular subsystem may have 
within the system architecture which stores general infor- 25 both Internal and External embodiments. For example, some 
mation on participants conducting electronic commerce with vendors may develop proprietary External Commerce Sub- 
each other. The participants might include manufacturers, systems to replace the Internal Commerce Subsystems origi- 
distributors, retailers, and customers; and information might nally provided by this invention. In those cases, the system 
include names and mailing addresses, preferred payment architecture would be able to accommodate either an Inter- 
methods, etc. 30 nal or External implementation of the Commerce 

For example, in the case of a household comprising Subsystem, with each electronic commerce participant being 
multiple customers, some customer data will be household- able to select a combination of specific implementations that 
specific (e.g., a single shipping address) while other cus- best suits the participant's needs, 
tomer data may be customer or store-specific (e.g., Mom's External Commerce Subsystems 

Macy's credit card number). This separation of household 35 Many existing Commerce Subsystems used for physical 
and customer data would also be useful for promotions commerce can be used far electronic commerce without 
based on household demographics, and other applications, modification. These technologies are referred to as External 
where it is net necessary to send repeat advertisements to all Commerce Subsystems. Such subsystems operate identi- 
members of a household. calfy whether the sale occurs in a physical or electronic 

The Observations Subsystem provides a system for 40 store, so that their implementations are the same in both 
recording events representing observable data that results physical and electronic commerce. They could include: 
from customer interactions. A program object called a "col- Customer Accounts Subsystem, Participant Subsystem; 
lector" communicates events to an event recipient. The event Order Fulfillment; Payment Handler; Product Database; 
recipient can either record the event for subsequent histori- Shipping; and Tax. 

cal analysis, or present it for real time analysis. 45 Examples of well-known existing implementations of 

The Electronic Storefront, which is analogous to a pbysi- these subsystems are: VESA's computerized credit card 
cal store's physical layout, is the graphical user interface network (Payment Handler), various catalog sales' central 
presented to a customer browsing that store. warehouse operations (Order Fulfillment), FedEx's on-site, 

The Store Management Dashboard 20 allows store man- personal computer-based shipping calculator (Shipping), 
agement to change prices, offer incentives, collect customer- so and AVP's tax calculator (Taxing), 
based and store-based sales data, and perform targeted Many physical stores will have different External Corn- 
advertising, i.e., interact with the various Internal and Exter- merce Subsystems that they will want to continue using in 
nal Commerce Subsystems discussed earlier. It is anticipated the context of an electronic store. For example, other Pay- 
that stores will want to use their own proprietary Electronic ment Handler systems might include CheckFree's automatic 
Storefronts, so the architecture provides an interface to be 55 check handling system for non credit-card acceptors or 
used by an existing Electronic Storefront rather than pro- in-house "legacy systems' 1 for large department store chains, 
viding the Electronic Storefront itself. For example, existing Therefore, the system architecture must accommodate a 
commercial services having proprietary electronic store- wide variety of existing subsystems. Rather than developing 
fronts (e.g., America Online' s or Compuserve's home shop- new subsystems to displace individual stores' established 
ping forums) will probably want to continue to use those 60 preferences, the system architecture provides a set of appli- 
storefronts even if they become networked into a broader cation program interfaces (APIs) through which owners or 
electronic commerce architecture provided by this invert- vendors of External Commerce Subsystems can easily 
tion. 'Vrap" their products for connection to the general system 

Architectural Openness and Flexibility architecture. 

As discussed briefly above, the Commerce Subsystems 65 Internal Commerce Subsystems 
may be categorized as either external or internal. Hie The remainder of the Commerce Subsystems are called 
difference between the two is that in the former, the inven- Internal Commerce Subsystems — those where existing sub- 
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systems for physical commerce can not be directly used in graphic data, and methods available to the participant for 

electronic commerce, so that separate electronic counter- payment Access by a store to the information about a 

parts must be developed for use by electronic stores. participant is controlled by a flexible mechanism in the 

Such Internal Commerce Subsystems might include: Participant Subsystem, This mechanism supports enforce- 

Incentives; Observations Subsystem; Participant Sub- 5 ment of a variety of privacy policies. These policies may be 

. system; Pricing; Promotions; Sales Representative; and specified by the operator of the Commerce System, by the 

Security. individual participant, or by a combination of the two. 

Some of these subsystems, though not currently in exist- Different privacy policies may be specified for each element 

ence for use in electronic commerce, nevertheless use well- of the participant data for each individual customer. The 

established, commercially available technologies. These 10 policy data is stored with a Participant Program Object 112 

could include Oracle or Sybase databases for the database as part of the privacy controls, in a Participant Subsystem 

components of the Observations and Participant which will be described in greater detail with reference to 

Subsystems, and RSA Public Key encryption technology for FIG. 5. 

the Security Subsystem. These Internal Commerce Sub- For each payment method, the Participant Program Object 

systems are developed by simply wrapping the aforemen- 15 112 contains a short token used to describe the payment 

tioned technologies with the appropriate hooks to interface method and a password that will be used to validate attempts 

with the standardized APIs. The process is similar to that to use the payment method. 

third party developers would use to create interface- Typically, the Participant Program Object 112 is created 

compatible External Commerce Subsystems. for a participant 12 at the time that the participant is 

The four remaining Internal Commerce Subsystems, 20 registered with the electronic service from which he or she 

which are not generated by modifying existing technologies, will interact with the commerce system. For example, if the 

are the Incentives Subsystem, the Pricing Subsystem, the electronic service is an online service such as Compuserve 

Promotions Subsystem, and the Sales Representative Sub- or America Online, a Participant Program Object 112 is 

system. The details of these will be apparent from a reading created at the time the customer enrolls with the online 

of the specification as a whole. 25 service. Likewise, if die electronic service is a cable televi- 

TTT. Implementation sion provider, a Participant Program Object 112 is created at 

To implement the above, and as will be apparent from the the time that the participant 12 begins subscribing to the 

description of FIG. 2, the system comprises a set of program cable television provider. In this way, sensitive information 

objects. such as credit card account numbers and passwords may be 

A program object is an integrated collection of data and 30 provided using a secure means at account initiation, 
functions that describe an entity or business function, and The Participant Program Object 112 communicates with a 
the operations that can be performed on or by the entity or Customer Monitoring Object or Sales Representative Pro- 
business function. Program objects can also access gram Object 114. Sales Representative Program Object 114 
databases, and serve as interfaces to non-object-oriented is a program object that is created when the customer selects 
subsystems. The program objects may be, for example, 35 a store. The Sales Representative Program Object 114 has 
objects in compliance with the Object Management Group 1 s access to information, kept by the store, about the customer 
(OMG's) Common Object Request Broker Architecture and also controls me flow of a transaction processing session 
(CORBA). and forms part of an Internal Commerce Subsystem 16 

CORBA provides mechanisms by which objects may shown in FIG. 1. As will be described in detail, Sales 
transparently make requests and receive responses. CORBA 40 Representative Program Object 114 is used to obtain infer- 
also provides for an Object Request Broker (ORB), which mation regarding items that are the subject of the 
provides interoperability between applications on different transaction, and initiate clearance for payment and order 
computers in heterogeneous distributed environments and fulfillment 

seamlessly interconnects multiple object systems. The The Sales Representative Program Object 114 is analo- 

advantage of compliance with an architecture such as 45 gous to a sales representative in a store. Just as a sales 

CORBA is that the program objects may be distributed representative has the responsibility of monitoring the cus- 

among various computers according to the business needs tamers activity by being aware of prices of products and 

and responsibilities of the entities involved in the system. discounts available to the customer, and by initiating 

FIG. 2 illustrates a number of the program objects nec- completion of the transaction, the Sales Representative 

essary to implement an embodiment of the invention. As so Program Object 114 carries out these tasks in the online 

such, the figure shows a plurality of program objects inter- commerce system. 

acting to support the execution of a commercial transaction. Interaction between the Sales Representative Program 

To begin with, a participant or customer 12 interacts with Object 114 and the customer 12, to communicate informa- 

the system 10 by way of a user interface 13. User Interface tion about, for example, items desired to be purchased, is 

13 may be in the form of a video terminal, a cable television 55 through the User Interface 13. 

set-top device, a touch-sensitive kiosk screen, a touch-tone The Sales Representative Program Object 114 communi- 
telephone, or any other device or combination of devices cates with a Product Database 116 through Pricing Engine 
capable of reproducing or otherwise displaying human Intel- 120. Product Database 116 is part of the External Commerce 
ligible audio and/or visual information to a customer 12 and Subsystems IS and is a computer file or set of computer files, 
capable of converting human input to a discrete signal 60 including, if necessary, supporting software components for 
capable of being recognized by a computer. the retrieval of data. Product Database 116 includes infer- 
Notwithstanding this interaction, however, it is a Partici- mation regarding items that arc offered as the subject of 
pant Program Object 112 that represents the customer 12 in transactions. This information includes the name of the item, 
the commerce system. The Participant Program Object 112 item identification numbers, standard price for the item, 
contains information that identifies the participant 12, and 65 manufacturer, etc. The Product Database 116 may be imple- 
additional information about the participant, for example, mented using any of a number of commercially available 
the participant's name, address, privacy controls, demo- database systems, such as Oracle or Sybase. The Product 
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Database 116 accepts function calls from the Sale Repre- In the example depicted in this FIG. 2, Participant Pro- 

sentative Program Object 114 to provide information about gram Object 112 and User Interface 13 are configured in 

a particular item. what can be called a Customer Contact System 140. Cus- 

Also provided is Distributor Program Object 118, which tomer Contact System 140 may be, for exanmle, an online 

is part of the Internal Commerce Subsystems 16, and is a 5 service such as Compuserve or America Online, an apph- 

program object that provides information regarding Cou- nation interface at a cable television site accessed) remotely 

£ms 119 to the Electronic Storefront 14. Coupons are data by a aistomer using a set-top box, or a World-Wide Web 

pwua ^ uiv^wiwiii . *i. * (WWW) site on the Internet accessed by a customer using a 

sttuctures that describe ^^^^^ WW browser application across a TCP/IP connection. 5 

discounts that made available to the customer to encourage ShnnaA y 9 mc Sales Representative Program Object 114, 

purchase of items, and are further described below. 10 p^^. Data base 116, Pricing Engine 120, Tax Engine 122, 

A Pricing Engine 120 is responsive to function calls from shipping Cost Engine 123, Payment Handler Interface 124, 
Sales Representative Program Object 114 is also provided. ^a^^ Payment Handler 126, Order Fulfillment Sub- 
Pricing Engine 120 is a program object that provides infor- system 128, and Order Fulfillment Legacy System 130 are 
mation about the price of a set of items selected for purchase. configured in an In-Store Processing System 142. In-Store 
The Pricing Engine 120 accesses the Product Database 116 15 processing System 142 may be, for example, a computer 
to determine attributes of selected items, and applies incen- system used to administer one or more of the electronic 
tives obtained from Distributor Program Object 118 to Storefronts 14 shown in FIG. 1. 

determine a price that will be charged to the customer. FIG. 3 depicts only the compartment level view of the 

The Tax Engine 122, part of External Commerce Sub- system depicted in FIG. 2. In-Store Processing System 142 

systems 18, is a program object that determines what tax, if 20 is depicted in communication with Customer Contact Sys- 

any, should be applied to a particular transaction, based upon tern 140. 

the items that are the subject of the transaction, the geo- As an expansion of this view, FIG. 4 depicts a compart- 
graphical locations of the participant and the electronic ment level Yiew of the system, with a plurality of In-Store 
commerce system, etc. The Tax Engine 122 is responsive to Processing Systems 142. In such a configuration, the corn- 
function calls from Sales Representative Program Object 25 merce system operates to facilitate commerce with multiple 
114 and may be implemented, for example, using a com- commercial entities, analogous to the shopping mall sup- 
mcrcially available tax calculation system, such as the AVP porting multiple stores as described above. 
Tax Engine. IV. Transaction Processing 

The Shipping Cost Engine 123, part of External Com- Overview of an Electronic Store Transaction 
merce Subsystems 18, is a program object that deterrnines 30 To mare fully understand the operation of the invention, 
the cost, if any, of shipping purchased items to the location it is useful to concentrate on a transaction in a single 
designated by the customer, based upon the properties (such electronic store. FIG. 5 shows an overview of a simplified 
as weight, size, and special shipping requirements) of the logic flow for a typical transaction, 
items that are the subject of the transaction, the geographical A Customer/Participant 12 enters an electronic storefront 
locations of the participant and the electronic commerce 35 14 and is presented with the store's Product Database 116 in 
system, etc. The Shipping Cost Engine 123 is responsive to connection with in-store sales, presented by the Sales Rep- 
function calls from Sales Representative Program Object resentative 114 together with an Incentives Subsystem 160 
114 and may be implemented, far example, using a com- and narrowcast advertising targeted at the Customer through 
mercially available shipping cost calculation system. a Promotions Subsystem 162 based on the Customer's 

Payment Handler Interface 124 is provided to initiate 40 demographics or purchasing habits as defined by a Partici- 

payment for a transaction. This is a program object that is pant Subsystem 164 and Customer Accounts Subsystem 

responsive to Sales Representative Program Object 114. 117. 

Topically, the Payment Handler Interface 124 will serve as In response, the Customer passes product or service 

a front-end to convert an object-oriented function call, such selections to the Sales Representative 114. The Sales Rep- 

as a CORBA call, to a call to an External Payment Handler 45 resentative 114 obtains pricing information from the Incen- 

126, part of External Subsystems 18. The External Payment tives Subsystem 160 to get pricing rules, and then passing 

Handler 126 may be implemented using a commercially the selection list and the pricing rules to the Pricing Engine 

available payment handling system, such as Visa Corpora- 120, which calculates and returns discounted prices by 

u'on's VISAnet (not shown). niatching the selection list against the pricing rules using 

To initiate delivery of the selected items to the customer so product information from the Product Database 116. 

Order Fulfillment Subsystem 128, a program object that is The Sales Representative 114 then calls subsystems such 

responsive to Sales Representative Program Object 114, is as Tax Engine 122 to calculate Tax and Shipping. Thereafter, 

provided. Topically, the Order Fulfillment Subsystem 128 the Sales Representative 114 returns a total price to the 

will serve as a front-end to convert an object-oriented Customs 12, who returns a final order to the Sales Repre- 

function call such as a CORBA call to a call to an external 55 sentative. 

subsystem that performs order fulfillment An example of Thereafter, the Sales Representative 114 arranges for 
such an external subsystem is Order Fulfillment Legacy Payment This includes querying the Customer far a pay- 
Subsystem 130. The Order Fulfillment Legacy Subsystem ment method (e.g., VISA card) and a means of authenticat- 
130 may, for example, be a store's existing subsystems for ing the identity of the Customer (e.g., a password); querying 
delivering a product or a service to the consumer. 60 the Participant Subsystem 164 for payment information 
This figure also depicts one possible configuration of corresponding to the payment method (e.g., looking up the 
components distributed among multiple logical compart- customer's VISA card number, which is secure from the 
ments of the commerce subsystem A logical compartment store); calling a Payment Handler 126 to validate the pass- 
may be a distinct computer system, or it may be a set of word and to authorize the credit transaction with an external 
resources in a computer system or set of computer systems 65 payment network (not shown), e.g., VISAnet 
to which the enterprise responsible far the compartment has Next, the Sales Representative 114 transmits the order to 
access. the Order Fulfillment Subsystem 128. Order Fulfillment 
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Subsystem provides Sales Representative 114 with a receipt 
to be placed in the Participant Program Object 112 as an 



indication that the order has been processed; calls Order mterfece BV_SaksRcp Fac { 

Fulfillment Legacy System 150 to arrange for delivery of B\LsafesRep crcato_*«p ( 

goods to the customer; and calls Payment Handler Interface 5 m BVPaiticipaat part, 

126 to settle the payment Order Fulfillment Legacy System J° BV^cniirciHstributorLiat a, 

130 also feeds back data to update the Participant Subsystem y t 

and the Store Sales database, part of Observation Subsystem ' 
168 

\ io Here, a function create_jsrep of type BV_SalesRep 

Details of the Transaction receives two inputs: part, of type BV_Participant (and 

The above reflects an overview of a typical transaction. To identifying Participant Program Object 112); and dl, of type 

more fully understand and describe this transaction it is BV„mcentiveDistrmmoxIJst describing a list of Distributor 

useful to divide it into its three phases: Program Objects 118. 

. The first input, part is inf conation on the customer's 

(a) initiation of a shopping session; « household transmitted from Participant Subsystem 164 to 

(b) selection of items to be purchased; and Sales Representative Object 114. The second input, dl, is a 

(c) completion of the shopping session. list of all currently available Incentive Distributors associ- 

Each of these phases is described in greater detail below: ated wi™ me store - 

, * T ... * c _- Following initialization of Sales Representative Program 

(a) Initiation of Session ^ Qbject U4 ^ e ^ Representative Factory 115 passes a 

FIG. 6 depicts the initiation of a shopping session using pointcr to me Participant Program Object 112 to the Sales 

the system of the invention. Representative Object 114. The pointer is a data area that 

When the Customer 12 "enters" a Storefront 14, Partici- indicates where its corresponding program object can be 

pant Program Object 112 is retrieved from the Participant found. Thus communications between the Participant Object 

Subsystem and activated. Storefront 14 determines what 25 112 and the Sales Representative Program Object 114 can be 

Distributor Objects 118 exist to distribute coupons that can established. 

be used by this storefront This may be accomplished, for ^ a simple nondistributed implementation, the pointer 

example, through the use of a nameserver such as that a^y simply be an address of the location in the computer's 

specified by the CORBA Object Request Broker. Storefront storage at which the program object to which the pointer 

14 calls Sales Representative Factory 115, passing to it the 30 corresponds may be found. 

Participant Program Object 112 and the list of Distributor 1° 111016 complex implementations, such as an implemen- 

Objects 118. tation capable of being distributed across multiple computer 

Sales Representative Factory 115 is a special-purpose **** ^ ?* * ^J"" 00 fa * Q J°™ 

program object whose purpose is to create, or "instantiate - of * tokc ° ^"±l 0 ™ rc( £ cst br t ° k f 

a^rRiesentatWe PrWam Object 114. Sales Repre- 35 such as aCORBA-00^ 

sentative Factory 115 instantiates a Sales Representative of a particular obje^ handle, the ORB can then dnxct a 

Program Object 114 in response to a request from the ™* uest t0 use * e Jf™* 8 of a P 3 *"^ P 10 ^ ob ^ ect t0 

Storefront 14. Once created, Sales Representative Program ^tpogram object 

nw^ im inits ft i,s« ,>«if (b) Transaction Processing 

Object 114 initializes itseli. v ' ^ _ - _ b ^ . . , ^ A . 

: , ^ ^ ^. 40 Once the Sales Representative Object 114 is instantiated 

Sales Representative Program Object 114 obtains from ^ custQmer select ^ for purchase . FIG. 7 depicts 

Participant Pro^ Object 112 any Capons .119 Mthat have ^ s by which a ^om* does so. User Interface 13 

teenretmnedbyPar^ te ^ cagtmtg u ^ descriptions of items for 

shopping sessions. Sales Repre^n^ye Program O^ 114 ^ ^ Ufii mean s capable of being 

also calls Distributor Program Objects 11S to obtain any 45 ^ loyed F by the User Interface 13. For example, a full- 

additional Coupons 119 thatrepresent current sales in Store- 5^^^^ syst em such as an online service or a 

front 14. WWW session may employ icons associated with various 

After the Sales Representative Object 114 is created, it products and services, whereas an interactive cable televi- 

figuratively accompanies the customer through the store, s i on service may employ a product list that can be scrolled 

provides pricing information, authorizes the purchase 50 and from which items may be selected using buttons on a 

method (e.g., VISA), applies any applicable discounts (e.g., remote control device. 

in-store price discounts or coupon-based price discounts), When the customer 12 selects items for purchase, User 
and completes the sale (e.g., ships the items and arranges for interface 13 calls Sales Representative Program Object 114 
payment). In one embodiment of the invention, the Sales to inform that program object of the selected item. Sales 
Representative Object 114 is dedicated to the Customer 12 55 Representative Program Object 114 maintain* a Purchase 
until the Customer 12 completes that session but does not List 17*. In response to requests from User Interface 13 to 
outlive a shopping session. In another embodiment of the sc i cc t ^ item, Sales Representative Program Object 114 
invention, the Sales Representative Object 114 may span validates the selected item against Product Database 116 and 
several sessions. The life of Sales Representative Object 114 adds the selected item to the Purchase list 170. 
is terminated upon payment (or billing frequency), which is go This is done using a call that interrogates the Product 
specified by Store Management. For example, if billing is Database 116 for Product Data consisting of an item des clip- 
per session, the Sales Representative Object 114 only lasts tion and its list price at the time of selection, 
for that session; but if billing is monthly, the Sales Repre- The selection of an item for purchase is not a commitment 
sentative Object 114 lasts for the entire month. t0 purchase. It is analogous to a shopper placing an item in 
The call to the Sales Rep Factory 115 to create a Sales 65 a shopping cart in preparation for a purchase. Just as a 
Representative Object 114 may be coded using the CORBA shopper may elect not to purchase a selected item, User 
Interface Definition Language (1DL) as follows: Interface 13 may also communicate to Sales Representative 
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ftogram Object 114 that the customer does not wish to of the mother of the household, the token might contain the 

purchase an item that has previously been selected. In string **Mom*s Visa." 

response to such a call, Sales Representative Program (ii) Selection of Payment Method 

Object 114 removes Che corresponding entry from Purchase in response to output from the function call given directly 

list 170. 5 above, and as shown in Step 181, Sales Representative 

Sales Representative Program Object 114 validates all Program Object 114 calls User Interface 13 to obtain the 

applicable coupons against the store's Redemption Database customer's selected method of payment As shown in detail 

172 (which is part of Incentive Subsystem 160) and obtains m pjQ gA, in step 181 Sales Representative Program Object 

the pricing rules for the incentive programs that those n4 calls user Interface 13, passing to it the list of payment 

coupons represent The Redemption Database 172 accom- 1Q method tokeas that correspond to the payment methods for 

pushes this by referencing the incentive programs ; recorded whkh fc ^oma is authorized. User Interface 13 presents 

in the Redemption Database 172 and referencing the pacing ^ ^ tQ me Corner, fox selection of a preferred payment 

rules from the corresponding Incentive Program Objects. met hod and the provision of a password necessary to aulhen- 

Optionally, during the course of selecting ; items for ticalehisorhcillseof the payment memcKLTliemfoniiation 

purchase, Sales Representative Program Object 114 may call 15 nted t0 me 12 ^ described below in greater 

Pricing Engine 120 to determine the total cost of the items dctail wim ^teence to mGt 9 , User Interface 13 computes 

currently selected and placed on Purchase list 170. Sales & payment authorization token, called the Response to 

Representative Program Object 114 passes the purchase Ust md ^ ovidcs U to Sa i es Representative Program 

and any applicable pricing rules to Pricing Engine 120. w n4 ^ Responsc to challenge is an encrypted 

Pricing Engine 120 obtains additional item attributes from ^ tokcfl bascd u ±c passward entered by the user. 

Product Database 116 and calculates the proposed total cost ™ ^ Val f dation 

of the selected items with discounts from applicable incen- ^ ^ rcsponse to output ^m me ranction ^ 

tives via the pricing rules. ^ the payment method selected and the password entered by 

This total cost information is returned to Sales Represen- ^ 12 wiU ^ validated. In step 182, Sales Rep- 

tatiye Program Objecl t 114 .Sales ; Rer^esentauveftogram 2$ rcsentative ^ Qbject U4 recdves ^ method of 

Object 114 provides this information to User Interface 13, flt and mc t authorization token from 

which displays it to the customer for approval or for further ^ 13 ^ lg3 Saleg Represe atative Program 

item selection and/or deselection. This price calculation may Gbject U4 ^ Paymcirt Handler Interface 124 to validate 

be performed, for example, after every selection/deselection ^ selected method of payme nt, passing to the Payment 

operation initiated by the customer, or in response to the 3Q Handier j^^^ U4 the data received from the customer 

customer's specific request to generate a current total. ^ s ^ 

Thereafter, the transaction can be completed. mQ 8R ' ^ 183 m dctail as performed by 

(c) Transaction Completion 1 . Payment Handler Interface 124 and Participant Program 

FIGS. 8, 8A and 8B depict the completion of an online ^ m fa 183A ^ pay^t Handler Interface 124 

transaction in the commerce system, Transaction completion ^ obtamj} ^ Response t0 challenge token that was supplied 

is performed by Sales Representative Program Object 114 in [n ^ this will be passed by the Sales 

W ±? C o°L^ FT 1 ^ 1 cT Representative Program Object 114 in the call to Payment 
in FIG. 8. HG. 8A depicts the steps performed by the Sales Mcifacc fa m st ^ 183 p aymcnt Handler Inter- 
Representative Program Object 114 and FK3. 8B depicts the face 124 ^ Partic ipant p^g^ object 112, passing to it 
steps perform^ by Pay ment Handler ^terface 124 in con- ^ ^ se tQ ^ tokcn . Participant Program 
junction with Participant Program Object 112, HGS^SA and ^ m &en calcuUtes> m step 18 3C, a reference pay. 
8B and should be referenced in conjunction with HG. 8. ment autnorizatioil tokcn . m reference paymcnt authori- 
(i) Obtaimng Payment Alternatives 2ation tokBn is ^ enCTypte<1 tokeil based upon the password 

In Step 180, Sales Representative Program Object 114 ^ from ^ Partidpant program object 112. In step 

calls Participant Program Object 112 to obtain a Ust of +J mJ) Paracipant program Object 112 compares the 

methods of payment that are available to the customer. In Res se t0 avenge token received from User Interface 

response to the call, Participant Program Object 112 passes 13 ^ ^ refereQce payment authorization token, to vali- 

to Sales Representative Program Object 114 a list of all ^ me autharity of mc customer to use die selected 

payment methods that the customer is authorized to use. payment method. If the two tokens are equal, Participant 

The call may be implemented with the following code: ^ Qbject 112 provides to the Payment Handler Inter- 

face 124 the information needed to effect an authorization to 

void prcpaie_to_buy ( charge the selected payment method; generally this will 

out BV^aymcctMomtoniPaymcnflist aiias_iist, include an account Dumber, expiration date, cardholder 

out BV_Security::U6CiCbaUeoge challenge) name, and the like. 

raises (BV^nvaiidstate); 55 ^ Step Payment Handler Interface 124 verifies that 

— — ■ — — — — — — ~— — —— — ^ participant Program Object has successfully verified the 

Parameters alias_list and challenge are outputs from the Response to Challenge. If so, in Step 183H, the Payment 

function. Handler Interface 124 calls External Payment Handler 126 

For each paymcnt method, the Participant Program Object to obtain an authorization to charge. External Payment 

112 provides the Sales Representative Program Object 114 so Handler 126 is typically a computer system operated by the 
with a short token used to describe the payment method and institution supporting the payment method. For example, if 

a challenge that will be used to validate attempts to use the the customer selects a Visa credit card as a paymcnt method, 

payment method. The token is a text string that identifies the then Payment Handler Interface 124 will call the VKAnet 
payment method using words that are familiar to the system for authorization to charge the selected Visa account 

customer, but does not contain any confidential information. 65 External Payment Handler 126 notifies Payment Handler 
For example, if a customer is authorized for a payment Interface 124 that the charge to the selected paymcnt method 
method using the Visa credit card account held in the name will be accepted. 



03/30/2004, EAST Version: 1.4.1 



5,7: 

17 

If the tokens are not equal, Payment Handler Interface 124 
in step 183G sets an indicator that the selected payment 
method was not properly authorized. Following either step 
183G or 183H, Payment Handler Interface 124 in step 1831 
returns control to Sales Representative Program Object 114. 
Typically, in this step Payment Handler Interface 124 may 
indicate success by supplying to Sales Representative Pro- 
gram Object 114 an Authorization Object that describes the 
authorization to charge. 

In step 184, Sales Representative Program Object 184 
checks whether Payment Handler indicated that the selected 
payment method was not properly authorized. If it was not 
authorized, Sales Representative Program Object 114 
returns to step 181 to again prompt the customer to reenter 
the method-of-payment data, or optionally aborts the trans- 
action. 

One benefit of this method is that it avoids the transmis- 
sion of sensitive information such as credit card account 
numbers to Sales Representative Program Object 114. No 
account numbers are transmitted between User Interface 113 
and Sales Representative Program Object 114. 

(iv) Order Fulfillment 

Once authorization to charge been effected, and as shown 
by Step 185, Sales Representative Program Object 114 calls 
the Order Fulfillment Subsystem 128, providing it with the 
list of items ordered by the customer. Order Fulfillment 
Subsystem 128 typically calls an existing Order Fulfillment 
Legacy System 130 to generate shipping manifests and 
perform other activities needed to ship the selected products 
to the customer. 

(v) Generating Receipt 

Following step 185, Sales Representative Program Object 
114 creates a receipt 192 and passes it to Participant Program 
Object 112 for storage to be used if later verification of the 
order is required. 

Typically, the step of creating the Receipt 192 may be 
accomplished by the steps shown in FIG. 8 A. In step 186, 
Sales Representative Program Object 114 replicates Pur- 
chase List 170. In Step 187, Sales Representative Program 
Object 114 (hen modifies the replicated Purchase List 170, 
to indicate that the resulting data structure is a receipt, e.g., 
by setting a flag. In Step 188, Sales Representative Program 
Object 114 calls Participant Program Object 112, passing it 
the newly created receipt 192 for storage. 

(vi) Settlement 

When the selected products are indicated as shipped, 
Order Fulfillment Subsystem 128 calls Payment Handler 
Interface 124 to request the payment that previously autho- 
rized in step 183D. Payment Handler Interface 124 again 
calls External Payment Handler 126 to convert the authori- 
zation to charge to a payment order. 

(vii) Implementation of Sections (iii) to (vi) 

The components of the transaction described above under 
Sections (iii) to (vi) are completed by the following calls 
which are described in detail below. 

Once the customer 12 has selected a choice of payment 
type, the Sales Representative Object 114 then calls a buying 
function of the form: 



BV_Receipt buy ( 

in B V_PaymcntMociitor: iPaymentAlias paym«m_type, 
in BV_FaymeDtMcMiltor.:VserNaiDe usa; 
in BV_J5ecurity::UserRespcnse response, 

ID BV_Boolean external paymmt mrthnd, 

in BV PaymentMethod cpm 

) 
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-continued 

raises ( 

BV_CrcditAuth, 
BV_ShipphgCalc, 
5 BV_JRricin«Calc, 
BV Redemption, 
BV_JFulfiDnient t 
BV_Abcrt, 
BV_JnvalidState 

*. 

10 ■ 

This call performs a number of steps including: 
(i) creating an invoice listing the items to be bought and 
the shipping destination, 
13 (ii) calling the Pricing Engine 120 to calculate a subtotal, 

(iii) calling the Order Fulfillment Subsystem 130, 

(iv) calling the Tax Engine 122, 

(v) computing the total price for the order, 

(vi) authorizing payment for the order, 

(vii) fulfilling the order, 

(viii) redeeming coupons, 

(ix) returning unused coupons to the customer, and 

(x) creating a receipt for the customer. 
25 These steps are discussed in turn, below. 

The first step is a call to the Pricing Engine 120 to 
compute a subtotal for the items in the customer's order. The 
Sales Representative Object 114 passes the customer's order 
and all the currently existing Pricing Rules to the Pricing 
30 Engine 120, which returns a Total List Price, a Total Dis- 
count and an itemized price list 

The actual interface to the Pricing Engine 120 takes the 
form: 



BVL^AmendmenlList eval( 

in BV _JtemLtst target_items, 

in BV ItemList baskeLjtems, 

in BV_JnccDdvcList_incentivfts; 
out BV__Money totaLJttt_price, 
out BV_Money tota]_discount 



The first two inputs, target_Jtems and basket_items, 
together comprise the Customer's order. Target items are 
those items that are discountable. Basket_Jtems are those 
items that are nondiscountable, but which may be required 
to support discounting (e.g., they may contribute to meeting 
a quantity requirement). 

The third input, incentives, is a list of all currently existing 
store incentives. Each Incentive takes the form: 



struct BV_JvffHtrve ( 

long 3pplicatioiL_count; 
boolean valkL_w ith_others; 
BV_PriciugRule rule; 

>; 



where appttcation__count is the number of times the dis- 
count may be applied; 
60 valid„with_others is TRUE if the coupon can be applied to 
items already subject to a pricing change and FALSE 
otherwise; and 

rule is the pricing rule defined by the Store Management via 
the Store Management Dashboard 20 (as discussed below). 
65 The comparison of items to predicates (described in detail 
below with reference to FIG- 11) uses a pricing algorithm as 
follows: 
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Set the total_Iist_price to $000 
Set the totaL-discouat to $0.00 
For each item in tvget_items: 

Add the Hem's list price to the total_Jist-_price 

If the item is no longer discountable, continue to next item 

Por each incentive: 

If the rule matches and yields an adjustment, then Store the citem, incentive, rule, adjustmenO 

quartet in an array of results 

Mark item no longer discountable if the incentive is not valid with other offers 
If the adjustment is an amount, modify the totaJL_discount accordingly 

End if 

End mis incentive; process next incentive in sequence 
Return the array of results to (he Sales Rep. 



After computing the totaLJist_price and totaL_discount monitor store sales data, and 4) the Participant Subsystem 

the Sales Representative Object 114 invokes a subtotal 164 (owned by service provider) and Customer Account 

function to calculate the subtotal^total _Jist_price-total__ Subsystem 117 (owned by store) to collect customer usage 

discount The Sales Representative Object 114 then invokes data. Of these, Item 1, incentive creation, which relates 

a shippiog_cost function to pass the order to an external mostly to pre- sales activity, is discussed here. 

Shipping Subsystem that calculates shipping costs. This is 20 Creating Incentives 

typically one of several existing legacy systems which In overview, and as shown in FIG. 10, the Store Man- 
interface to the electronic store through the electronic mall's agement uses Store Management Dashboard 20 to interface 
Shipping APL Similarly, the Sales Representative Object with the Incentives Subsystem 160 to create Incentive 
114 calls an external Tax Subsystem to calculate the taxes. Programs 250. 

Sales Representative Object 114 then adds the subtotal, 25 Information specified in creating an Incentive Program ^ * 

shipping, and tax to give a total price. 250 would include the name and description of the incentive, / J"* AA>t#JuiA*&' 

The next step is to authorize payment, as described above its starting and ending dates, its sponsor, and the price — * 

in detail After the sale is authorized, any coupons 119 that discount Incentive Programs2 50 are created independently f^iy 

were actually used can be redeemed (as will be described of actual shopping sessions^ although they may also be ^ 

below). Any unused coupons 119 are released back to the so created while customers are shopping in the store. rtntnt KJ l 

Sales Representative Object 114 to be returned to the Incentive Programs 250 might include: in-store (public) 

Participant Program Object 112 within Participant Sub- price discounts, coupon-based price discounts, point-based 

system 164. Such coupons will be available for use by the frequent buyer discounts, or quantity discount cards, 

customer in subsequent shopping sessions. The function of these incentive programs 250 invention 

(viii) User Interface for Payment Selection 35 will first be described with reference to FIGS. 11 to 13 and 

FIG. 9 depicts one example of a User Interface 13 to select in the context of in-store price discounts, which are the most 

the preferred payment method as required by the system to common type of incentive. Thereafter the coupon-based 

the complete the transaction along the lines described above. price incentive will be discussed as an extension to the 

In the example, User Interface 13 displays a screen image general framework established by the discussion of in-store 

113. The screen image includes a display of payment options 40 price discounts. Frequent buyer discounts and quantity dis- 

212. The customer 12 (not shown) is presented with three count cards are discussed, 

payment options: 1) "Mom's Visa"; 2) "Jim's AMEX"; 3) (i) In-Store Price Discounts 

"Debit Jim's Checking Account." User Interface 13 also In-store price discounts are those where a customer need 

provides a means for the customer to indicate his or her not present a coupon to obtain the price discount, and which 

selection of payment methods. This means is depicted as 45 is contingent only upon the customer being in the store while 

selection input area 214. The customer may, for example, the incentive program is being offered. These are analogous 

type the number corresponding to the selected method of to publicly advertised weekly sales in a physical store, 

payment in this position. Although in-store sales are couponless from the custom- 

In addition, User Interface 13 provides a means for the er's perspective, it will be convenient, from the architec- 

customer to supply a password to authenticate his or her 50 ture's perspective, to think of in-store price discounts as 

identity and authority to use the selected payment method resulting from coupons mat are distributed to the customer 

In the example, this means is depicted as password entry upon entering the store. That is, the customer need not bring 

area 216. The customer may enter a password at that location coupons, but is automatically entitled to the appropriate 

on the screen. User Interface 13 then computes a payment coupons for any in-store sales. The coupon is used to inform 

authorization token using the password, and transmits the 55 the customer of all in-store price discounts in effect on 

method of payment selection and the payment authorization entering the electronic stare — analogous to handing a sales 

token to Sales Representative Program Object 114. flyer to a customer entering a physical store. This will be 

V. Storefront Setup Overview explained in detail in the discussion of an actual shopping 

Each electronic stare (represented by storefront 14) has a session below. The concept of a coupon for in-store price 
Store Management associated with it The Store Manage- 60 discounts is also useful because it establishes an incentive 
ment interacts with the electronic store through a Store framework that can be used for true coupon-based price 
Management Dashboard 20, which is typically a graphical discounts (where the customer must present a coupon to 
user interface running at a store manager's local personal receive the price discount), discussed below, 
computer. These interactions include interactions with 1) the In-store price discounts are embodied in Incentive Pro- 
Incentive Subsystem 160 to create discount programs, 2) the 65 grams 250 created by an Incentives Subsystem 160, as 
Order Fulfillment subsystem to configure or monitor the shown in FIG. 10. Each Incentive is expressed in a Pricing 
ordering process, 3) the Observations Subsystem 168 to Rule of the form: 
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street BV_JPricjpgRule ( 
long applkaticn__couat; 
boolean Yalid_witlx_otheis; 
BV_AdjustmentAfldPredicate rule; 

); 



where applicatioD__count is the number of times the dis- 
count may be applied; 

vafid_with__others is TRUE if the incentive can be applied 
to items already subject to a pricing change and FALSE 
otherwise; and rule contains the Adjustment and Predicates 
associated with the incentive: 



struct BV^AidjustmcntanriPredicate ( 
BV_AdjustoeaI adjustment; 
BV^predicateList predicates; 

); 



Each Pricing Rule is embodied in a Pricing Rule Structure 
260, illustrated in FIG. 11. Pricing Rule Structure 260 
typically comprises three data segments. These are an 
Adjustment Segment 262, a Predicate Segment 264, and a 
Qualifier Segment 266. Each Pricing Rule Structure 260 
includes one Adjustment Segment 262 and at least one of a 
Predicate Segment 264 and/or a Qualifier Segment 266. 
Each is discussed in detail below: 
(a) Adjustment Segments 

An Adjustment Segment 262 describes how the price of 
an item is affected if all Predicates Segments 264 (described 
below) are matched. Hie Adjustment 262 may be either a 
simple adjustment or a quantity adjustment A simple adjust- 
ment may either be fixed (e.g., sale price is $10), absolute 
(e.g., $10 off), or percentage (e.g., 10% off). A quantity 
adjustment includes the price-based discounting of a simple 
adjustment but also allows for quantity-based discounting. It 
takes the form: 



struct BV_Quanuty Adjustment ( 
unsigned short required; 
unsigned sbort discounted; 
BV_Simplc Adjustment adjustment; 
boolean less_at__equal; 

); 



where required is the minimum purchase requirement, dis- 
counted is the number of items discounted by this rule, 
adjustment is the simple adjustment, and less_or_equal= 
TRUE if the discounted items must be less or equal in value 
to the items making up the minimum purchase requirement. 

Thus, Adjustment Segment 262 contains at least two 
fields, which respectively indicate the type and amount of 
adjustment to be made to a price of an item. An Adjustment 
262 may be of a type None, Fixed, Absolute, or Percentage. 
The use of the amount field is dependent on the value of the 
type field. If Adjustment 262 is of type "None," no adjust- 
ment will be made to the price of an item at time of purchase: 
the item will be sold at the price indicated in Product 
Database 116. 

If Adjustment 262 is of type 4 *Fixeo\" the amount field 
contains a value to be substituted for the price indicated in 
Product Database 116. For example, if the amount field 
contains "20,** the price of the item will be $20, regardless 
of the value in Product Database 116. 

If Adjustment 262 is of type "Absolute " the amount field 
contains a value to be deducted from the price indicated in 
Product Database 116. For example, if the amount field 
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contains "20," $20 will be deducted from the value indicated 
in Pricing Database 116. 

If Adjustment 262 is of type "Percentage " the amount 
field contains a value, expressed as a percentage, that is to 
5 be deducted from the price indicated in Product Database 
116. For example, if the amount field contains "20," then the 
value indicated in Pricing Database 116 will be reduced by 
20 percent 

(b) Predicate Segments 

10 A Predicate Segment 264 is a specified condition an item 

must meet to qualify for the adjustment 
Predicate Segment 264 also contains at least two fields, 

respectively a type field that indicates the type of test that is 

used to determine whether the pricing rule may be applied 
13 to a given item at a given time, and a conditions field that the 

conditions that must be satisfied in order for the pricing rule 

to be applied. 

If Predicate 264 is of type 'Time of Day," the conditions 
field contains two values, which indicate the beginning time 

20 of day and the end time of day that delimit a period of time 
on which the pricing rule may be applied. For example, if the 
conditions field contains the two values corresponding to 
times of day "17:00:00" and "21 :00:00 " the pricing rule will 
be applied only between 5:00 PM. and 9:00 P.M. 

25 If Predicate 264 is of type "Date," the conditions field 
contains two values, which indicate the beginning and end 
dates on which the pricing rule may be applied. For example, 
if the conditions field contains the two values corresponding 
to the dates "Jul 1, 1996" and "Jul 31, 1996," then the 

30 pricing rule will be applied only during the month of July 
1996. 

If Predicate 264 is of type "Day," the conditions field 
includes a seven-entry boolean array, each entry of which 
corresponds to a particular day of the week. A "1" value in 

35 an entry indicates that the pricing rule may be applied on the 
day to which the entry corresponds; a "0" value indicates 
(hat the pricing rule is not to be applied on that day. For 
example, if the conditions field contains the value 
"0000011 " then the pricing rule will be applied only on 

40 Saturdays and Sundays. 

If Predicate 264 is of type *ltem Identifier," the conditions 
field contains a list containing one or more values that 
identify one or more items to which the pricing rule may be 
applied. For example, if the conditions field contains the 

45 value "XGD-100-56 " the pricing rule will be applied only 
to purchases of the item identified in Product Database 116 
as "XCD-100-56." 

If Predicate 264 is of type "Item Attribute," the conditions 
field contains a list containing one or more values that 

50 identify an attribute of one or more items to which the 
pricing rule may be applied. For example, if the conditions 
field contains the value "blouse," then the pricing rule will 
be applied to all items identified in Product Database 116 as 
having the attribute "blouse." 

55 If Predicate 264 is of type "Price " the conditions field 
contains a comparator indicator having a value such as 
"greater than," "less than,** eta, and a comparison value to 
be compared to the item's price. For example, if the condi- 
tions field contains a comparator value of "greater than" and 

60 a comparison value of "10," the pricing rule will be applied 
to all items identified in the Product Database 116 as having 
a price greater than $10. 

(c) Qualifier Segments 

Qualifier Segment 266 is used to identify additional 
65 discounts that may be applied other than on an item-by-item 
basis. For example, a Qualifier Segment 266 may be used to 
indicate that the pricing rule is to be applied only if 5 or more 
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items are purchased, if the transaction is for over $100 worth FIG. 12A depicts one view presented by the Dashboard 

of items, or to indicate that one product may be obtained at Client to storefront management. Specifically, FIG. 12A 

no charge with the purchase of a particular second product depicts a storefront manager establishing an Adjustment 262 

(ii) Coupon-Based Price Discounts of type "Percentage " indicating a 20% discount Dashboard 

In contrast to the Price discounts described above, 5 Client 280 displays a Pricing Term Details Window 282. 
coupon-based price discounts are those where a customer Pricing Term Details Window 282 includes a set of buttons 
must present a coupon in order to obtain a specified price 284 that are used to select the type of Adjustment 262 being 
discount in a present shopping session. Coupons may come defined, and a set of input areas 286 that are used to specify 
from previous shopping sessions in the coupon-accepting the amount of discount to be applied 
store (intra-store marketing), or from previous shopping 10 FIG. 12B depicts a second view presented by the Dash- 
sessions in other stores or from a manufacturer supplying board Client 280 to a storefront manager. Specifically, FIG. 
many stores (inter-store marketing). 12B depicts a storefront operator establishing a Predicate 

The same incentive creation mechanism discussed above 264 of type "Date" that is valid from Jul. 1, 1996 until Jul. 

for in-store price discounts is used to create coupon-based 31, 1996, and a Predicate 264 of type "Day" that is valid 

price discounts, which may be treated as a superset of 15 only on Saturday and Sunday. Dashboard Client 280 dis- 

in-store price discounts. The primary difference is that the plays Sales Details Window 288. Sales Details Window 288 

fields for total numbers of coupons and starting serial includes a set of two input areas 290 to specify the beginning 

number are now significant, for they are tools by which store and end dates on which this pricing rule may be applied, and 

management can limit coupon offerings and track coupon a set of Day-of-the-Week buttons 292 that indicate the days 

redemptions. 20 on which the pricing rule may be applied. 

Specifically, coupons other than in-store sale coupons are Referring now to FIGS. 12, 12A and 12B together, at the 
persistently retained in Participant Program Object 112 from control of the storefront manager and responsive to the data 
session to session, rather than being available only in the input by the storefront manager, Dashboard Client 280 
particular session and storefront in which the coupons were creates Pricing Rule Structure 300. Thereafter, Dashboard 
distributed. A coupon contains the same information as 25 Client 280 calls Incentive Factory 302, passing it Pricing 
in-store sale coupons as depicted, namely, the applicable Rule Structure 300. Incentive Factory 302 creates Incentive 
Adjustment Segments 262, Predicate Segments 264, and Program Object 160 reflecting the contents of Pricing Rule 
Qualifier Segments 266. In addition, such coupons also Structure 300. Dashboard Client 280 then calls Distributor 
contain a serial number and a digital signature. The serial Factory 304, passing it as a parameter Incentive Program 
fliinihfff jg an aThifraTily-sizftd numeric field that is unique for 30 Object 160. Distributor Factory 304 creates Distributor 
every coupon distributed by a Distributor Object, within a Program Object 118. As described before, Distributor Pro- 
range as specified at the time the Incentive Program that gram Object 118 will be made available to Storefronts 14, 
produced the coupon was created. When a coupon is and will provide Storefronts 14 with Coupons 119 at trans- 
redeemed, an entry for that coupon is made in Redemption action time. 

Database 172, indicating that the specific coupon with the 35 Dashboard Client 280 then calls Redemption Registry 

specific serial number has been redeemed. A coupon with a 310, passing to it as a parameter Incentive Program Object 

given serial number will only be redeemed if the Redemp- 160. Redemption Registry 310 records Incentive Program 

tion Database does not contain an indicator that the coupon Object 160 in Redemption Database 170. As will be recalled 

has already been redeemed. This prevents a coupon from and as described with reference to FIG. 7, Redemption 

being copied and used by more than one customer, and from 40 Database 170 will be used by Sales Representative Program 

being reused by the same customer more than one time. Object 114 to validate any Coupons 119 sought to be applied 

To maintain the integrity of the coupon's contents, the to a transaction, 

coupon also contains a digital signature. The digital sign a- FIG. 13 depicts the operation of Pricing Engine 120 in 

ture is a field whose content is the result of a cryptographic applying Coupons 119. In Step 300, Pricing Engine 120 

operation using, for example, the public key encryption 45 begins processing the Purchase List 170 and the associated 

method of RSA Data Security, Inc.. The cryptographic Coupons 119. 

operation operates on the contents of the remainder of the In Step 304, Pricing Engine 120 checks whether it has 

coupon, using a key to yield a digital signature, which is been passed any Coupons 119. If there are no Coupons 119 

stored in the coupon. With the digital signature, any modi- to be applied, Pricing Engine 120 skips processing of 

fication of the coupon will fail the redemption process when 50 incentives and proceeds to Step 306, 

the digital signature is compared to the remainder of the But, should any Coupons 119 apply, and as shown in Step 

coupon. This prevents, for example, a customer from alter- 308, Pricing Engine 120 selects the first of the Coupons 119 

ing a discount field to obtain a discount that is greater man for processing. In Step 310, Pricing Engine 120 selects the 

. that offered by the storefront. It also prevents a customer first of the Predicate Segments 67 in the Coupon selected. In 

from making a copy of a coupon and changing its serial 55 Step 312, Pricing Engine 120 evaluates the selected Predi- 

number so that it can be used in addition to the original cate Segment 264 to see if it applies to any of the products 

coupon. specified in Purchase List 170. In Step 314, if conditions 

Dashboard Operation specified in the Predicate Segment 264 are not met, Pricing 

As indicated above, Store Management interacts with the Engine 120 skips to Step 316 without applying the incentive, 

system through a Dashboard 20, typically hardware with an 60 If the conditions specified in the Predicate Segment 264 are 

associated display screen. Associated with Dashboard 20 met, Pricing Engine 120 in Step 318 checks whether there 

and as shown in FIG. 12, is a Dashboard Client 280, in die are further Predicates to be tested. If so, Pricing Engine 120 

form of software. As illustrated in FIGS. 12A and t2B the in Step 320 selects the next Predicate Segment to be tested, 

Dashboard Client 280 causes certain information to be and repeats from Step 312. 

displayed on the screen of the Dashboard 20. In order to 65 If all Predicates have been satisfied, in Step 322, Pricing 

better understand the operation of the Dashboard Client, Engine 120 applies the Coupon's Adjustment Segment 262 

these three Figures should be referenced together. to the price of the item as obtained from Product Database 
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116, i.e., by applying a new price for this transaction (for an 
Adjustment of type "Fixed"), by reducing the price by the 
dollar amount indicated (for an Adjustment of type 
"Absolute"), or by reducing the price by the percentage 
indicated (for an Adjustment of type **Percentage* , ) ; 

In Step 316, Pricing Engine 120 checks whether there are 
further Coupons 119 to be processed. If more Coupons 119 
remain to be processed, Pricing Engine 120 in Step 324 
selects the next Coupon to be processed and returns to Step 
310 to begin processing of the newly selected Coupon. If the 
last Incentive Program Object has been processed, Pricing 
Engine 120 proceeds to Step 326. In Step 326, Pricing 
Engine 120 computes the total cost of the transaction, with 
all Coupons 119 applied to Purchase list 170. In Step 328, 
Pricing Engine 120 returns control to Sales Representative 
Program Object 114. 
Observation Subsystem 

The Observations Subsystem 168 (FIG. 5) provides a 
system for recording events that represent observable data 
that results from customer interactions. FIGS. 14 and 15 
depict the Observation Subsystem 168. Observation Sub- 
system 168 comprises two types of program object. These 
are called collectors and event recipients. FIGS. 14 and 15 
depict three collectors 340, 342 and 344 and four event 
recipients 350, 352, 354 and 356. A program object called a 
"collector** communicates events to one or mare event 
recipients that have registered with the collector. Event 
Recipients are of two types, either Active Monitors or 
Loggers. 

Active Monitors perform real-time analysis of observa- 
tions. Each Active Monitor analyses certain types of data to 
produce a result that can be displayed to a store operator via 
the Dashboard. An example is an Active Monitor for moni- 
toring sales volume. Such an Active Monitor could receive 
events that describe orders purchased, and calculate a peri- 
odic total of items being purchased. The result would be a 
tracking of volume of orders on a periodic basis, e.g., hourly, 
which could be presented as a graphical display on the 
Dashboard. 

Loggers receive observations and write them to an exter- 
nal file in a predefined format, to produce a log of events that 
can be subsequently processed for historical analysis. For 
example, the log could be processed to determine if there is 
a trend signifying an increase over time of purchase of 
selected items. Also, purchases over time may be correlated 
with specific attributes of customers, e.g., income level or 
neighborhood. The resulting information could be provided 
to the Promotions Subsystem 116 to direct particular pro- 
motions to customers having similar attributes. 

FIG. 14 depicts the process of registration with a collec- 
tor. An Event Recipient such as Event Recipient 350 locates 
a Collector such as Collector 340 by means of a nameserver 
such as that specified by the CORB A Object Request Broker 
specification. Event Recipient 350 makes a call 360 to 
Collector 340, requesting to be registered with Collector 
340. FIG. 14 depicts Event Recipient 350 registering with 
Collector 340; Event Recipient 352 registering with Collec- 
tors 340 and 342; Event 354 registering with Collector 344; 
and Event Recipient 356 registering with Collector 342. As 
can be seen in FIG. 14, an Event Recipient may be registered 
with more than one Collector, and a Collector may register 
more than one Event Recipient 

FIG. 15 depicts the process of communicating Events 361 
from Collectors 340, 342, and 344 to Event Recipients 350, 
352, 354 and 356. Each Collector communicates events only 
to the Event Recipients that have registered with it 

Events that are transmitted by a collector may include 
events tracking general system navigation events, shopping 
events, purchasing events, and user-defined events. 
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General system navigation events may include, for 
example: Start-Session, End_Session, GenericJProfile, 
Enter _Service, Exit_Service, Enter_Category, Bxit__ 
Category, Enter_JLocation and Exil_Location. 

5 The Start.. Session event defines when a customer begins 
a particular commerce session. This may be, for example, 
when the customer logs on to Compuserve, America Online, 
etc This event includes the following data: session_Jd, an 
unique identifier identifying the session; session_ 

10 connection, which identifies how the customer is connected 
to the session; and datc_time, a date/time stamp. The 
End_£ession event defines when a customer exits a par- 
ticular session. This event includes the date: session_Jd and 
date_time. 

15 The Generic_Profile event is optionally generated at 
session start time to provide the Observation Subsystem 
with information regarding the customer. This event 
includes the following data: income_Jevel; gender; age; and 
geographic location. 

20 The Enter_Service event is generated when a customer 
begins using a particular storefront. This event includes the 
following data: scssion_Jd; service_Jd, which identifies the 
particular storefront in use by the customer, and date_Jime. 
A corresponding ExiCJService event is generated when the 

25 customer leaves the storefront, and includes session_Jd; 
service _Jd, and date_time. 

The Enter_Category event is generated when a customer 
selects a particular category of items to review within a 
storefront. It includes the following data: session_jd; 

30 service _Jd; fate_time; and category_id, which identifies 
the particular category being selected by the customer. A 
corresponding Exit_Category event is generated when the 
customer exits the category and includes session_id; 
scrvicc_jd; date_jtime; and category_Jd. 

35 The Enter _JjOcation event is generated to identify physi- 
cal location information about items being reviewed by a 
customer, for example, a particular spot on a printed catalog 
being reviewed by a customer. It includes the following data: 
session_Jd; service_Jd; date_time; and location_Jd, which 

40 may, for example, identify the cartesian coordinates within 
a particular catalog page being reviewed by the customer. A 
corresponding Exit_Location is generated when the cus- 
tomer stops reviewing the physical location and includes the 
following data: session_Jd; service_Jd; date_Jime; and 

45 location_JcL 

Shopping events may include, for example: Select _Jftem, 
Unselectjtem and View_Jtem. 

The Select_Jtem event is generated when a customer 
selects an item as a purchase candidate, akin to when a 

50 customer in a real store places an item in a shopping cart 
The Selectjtem event includes the following data: 
session_Jd; service_id; date_time; and producLJd, which 
identifies the selected product. 
The Unselect_Item event is generated when a customer 

ss decides not to purchase a particular item and un selects the 
item as a purchase candidate, akin to removing it from the 
shopping cart and replacing it on the store shelf. The 
Unselect_Jtem event includes the following data: session, 
id; service_Jd; date_jtime; and product_Jd. 

60 The VIew_Item event is generated when a customer 
requests derailed information about an item being offered by 
a storefront The View_Item event includes the following 
data: session_jd; service_id; date_time; and producc_id. 
Purchasing events may include, for example: Purchase. 

65 Item and Purchase_Order. 

The Purchase_Jtem event is generated when a customer 
actually purchases a selected item. When a purchase request 
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is made, one Purchase__Jtem event is generated for each ii. Coupon-Based Frequent Buyer Points 
item purchased. The Purchase Jtem event includes the A coupon-based price frequent buyer program is one in 

following data: sessional; service^id; date_time; which the customer presents a coupon, typically from a 

product_id; retail_price; discount__price; and incentive_ previous shopping session, for frequent buyer points in a 

name, which identifies any incentive that was applied to the 5 present shopping session. The frequent buyer coupon takes 

price. the same predicate/adjustment form as the price discount 

The Purchase_Order even is generated when a customer coupon, except that the adjustment tabes the form of points 

actually makes a purchase of one or more items. When a issued to a customer's frequent buyer account rather than an 

purchase request is made, one Purchase_Qrder event is instantaneous price discount. The customer may redeem 
generated for the entire order, regardless of the number of lQ . b a( varioU5 lcvclg t0 obtain actual price discounts, 

items in the order. The Purchase_Order event includes the ^ Quantity recount Incentives 

following da a: session_id; service^id; date fame; XfbMt^ ofmcentiv e program is the quantity discount 

number_ 0 f_ i tems_ P urchased; total_pnce; and totaU car<L Here> X e customer ha f a quantity discount card which 

Tl^-DefinedEventisagcn^ * clectroiucaUy punched each time the customer rnakes a 

be generated for any event tot is of interest to the operator « qualifying purchase When a required number of punches 

of me commerce system. Trie User ^Defined event includes have been made, the customer receives a discount, e.g„ 

the following data: session_Jd; scrvice_Jd; date_timc; "Buy 10, Get 1 Free" or $10 off. 
user_defined_type, which is a user-defined field that iden- CONCLUSION 
rifles the type of user-defined event being observed; and 

data__string, a string of data formatted according to the 20 In summary, the electronic mall is an example of a system 

needs of the developer. architecture in which interface-compliant implementations 

VTI Additional Features of these basic functional subsystems may be interconnected 

Variations on Above Disclosed Embodiment in a manner to suit the needs of a particular electronic 

a. Long-lived Sales Representative commerce participant The invention provides some sub- 
In the previously described embodiment of the invention, 25 systems directly (in the form of complete Internal Com- 

the Customer Monitoring Object/Sales Representative Pro- merce Subsystems), and other subsystems indirectly (in the 

gram Object 114 was created and terminated after each form of interfaces to External Commerce Subsystems), with 

shopping trip. In another embodiment of the invention, a each store being able to select the particular combination 

Sales Representative Program Object 114 may be longer- that best suits its specific needs. However, all subsystems, 

lived. Typically, Sales Representative Program Object ter- 30 whether External or Internal, are compatible with a set of 

mination is associated with customer billing. For example, if standardized subsystem interfaces. At the front end, a cus- 

the Electronic Storefront uses monthly rather than session tomer shops in the electronic store through an Electronic 

billing, the Sales Representative Program Object 114 would Storefront, and at the back end, the store management 

be terminated at the end of the monthly shopping cycle interfaces with and controls the various subsystems through 

rather than at the end of each shopping trip. 35 a Store Management Dashboard. 

In cases where a customer's Sales Representative Pro- jhe operation of the system described above includes 

gram Object outlives the shopping trip during which the exemplary code for selected interfaces where it is illustrative 

Sales Representative Program Object was created, termina- 0 f the operation of the subsystem. The source code is written 

tion of a shopping trip causes the Sales Representative using the Common Object Request Broker Architecture 

Program Object to become "dormant." Topically, this is 40 (CORBA) Interface Definition Language (IDL). 
effected by causing information regarding that shopping trip ^ publications and existing subsystems mentioned in 

to be stored and, for example, flags/pointers to be set so that Ms sp^nHon m herein incorporated by reference to the 

the Sales Representative Program Object can be "revived" same €Kte ^ t as tf each individual publication or existing 

or recalled at a later date. Subsequent shopping Rips can subsystems were specifically and individually indicated to 

then be initiated by recalling the particular Sales Represen- 45 be incorporated by reference. 

tetive Program Object assigned to that customer, hereafter, wm ^ ent to one of ^ ^ in ^ ^ ^ 

the transaction would proceed as in the earher-desenbed changcs F and modifications can be made thereto with- 

emb<»diment^except that the Sales ^esentative Ingram ^^g^ mc spiri t or a scope of the appended 

Object would only be terminated at the end of the shopping claim ^ e> r r 

trip if customer billing was performed. 50 y/e claim: 

b. Sales Representative Program Object for Multiple Stores t ^ fof facaitating commercial transactions, 
Similarly, the above description focuses on a Sales R*p- J , ofcustomers andatleast one supplier of 

resentative Program Object associated with asm^e supplier oycr a driven network capable of providing 

of items such as a store. It is, however, possible that a Sales wiwnmc&onsbetwetiL the supplier and at least one 
Representee Program Object can be created to attend to 55 ^ ^ each customer and including 

a customer interacting with a number of suppliers. In this mea ns and a display, the system comprising: 

embodiment, the Sales Representative Program Object can r _ \ v ' . 

7VT ' ~ « .„ tl a. means for causing at least one supplier to be repre- 

maintain a list of all items selected by the customer as well °- e u . 

as a reference to the supplier of each item. sented on the display for selection by the customer 

c. Frequent Buyer InceiuVes 60 u ^ * e 5« ^ ^ 

I In-store Frequent Buyer Points b > mcans foT effecting presentation of items on thedisplay 

Another type of in-store incentive is a frequent buyer far customer observation; 

points program. Here, the in-store incentive takes the form c an item database associated with a supplier and includ- 

of points issued to a customer's frequent buyer account iag information on presented items; 
rather than an instantaneous price discount. The customer 65 d. pricing means for receiving information from the item 

may redeem points at various levels to obtain actual price database to determine the cost associated with a pre- 

discounts. sented item; 
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e, a customer information database for storing informa- 
tion relating to a customer; and 

f. means for creating a customer monitoring object for 
each customer by referencing information, relating to 
that customer, which had been stored in the customer 
information database and upon the customer selecting 
at least one supplier such that the customer monitoring 
object is configured to operate by 

i. responding to customer enquiries, communicated 
through the input means, regarding a presented item 
by accessing the item database to retrieve informa- 
tion relating to said item and to present said infor- 
mation to the customer by means of the display, 

ii. receiving a customer's selection of a presented item 
through the input means, 

iii. communicating with the pricing means to have the 
cost of the item determined, 

iv. presenting the cost to the customer by means of the 
display, 

v. receiving customer communications, through the 
input means, indicating a desire to receive the item, 
and 

vi. passing a delivery initiation communication to ini- 
tiate the delivery of the item to the customer. 

2. The system of claim 1, further comprising a customer 
monitoring object configured to operate by: 

a. responding to customer enquiries, communicated 
through the input means, regarding a presented item by 
accessing the item database to retrieve information 
relating to said item and to present said information to 
the customer by means of the display, 

b. receiving a customer's selection of a presented item 
through the input means, 

c. communicating with the pricing means to have the cost 
of the item determined, 

d. presenting the cost to the customer by means of the 
display, 

e. receiving customer communications, through the input 
means, indicating a desire to receive the item, 

f. passing a delivery initiation communication to initiate 
the delivery of the item to the customer, and 

g. maintaining a list of selected items and present the 
customer with a cost of the selected items for approval 
by the customer before the customer monitoring object 
passes the delivery initiation communication. 

3. The system of claim 2, wherein the customer monitor- 
ing object is configured to present the customer with an 
opportunity to deselect an item whereupon the customer 
monitoring object communicates with the pricing means to 
have the costs of the remaining selected items redetermined 
and presented anew to the customer. 

4. The system of claim 2, further comprising order ful- 
fillment initiation means, responsive to the delivery initia- 
tion communication from the customer monitoring object, 
for initiating proceedings to cause the item desired by the 
customer delivered to the customer. 

5. The system of claim 4, wherein the order fulfillment 
means includes an interface with a shipping facility for 
facilitating the shipping of the desired item to the customer. 

6. The system of claim 2, further comprising a payment 
handler means for initiating customer payment for the 
desired item. 

7. The system of claim 6, wherein the payment handler 
means is responsive to communications from the customer 
monitoring object and receives information from the cus- 
tomer identification database in order to initiate customer 
payment 
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8. The system of claim 7, wherein the customer monitor- 
ing object is configured to confirm to the customer that the 
order for the item has been successfully processed. 

9. The system of claim 2, further comprising a payment 
5 validation system including 

means for causing the customer monitoring object to 
receive the information related to the forms of payment 
available to the customer and to present the customer 
with a selection of the forms of payment; 

10 means for receiving a first security code, related to a 
selected form of payment, from the customer, and 
means for validating the first security code by comparison 
to a second security code available to the customer 
monitoring object; 

13 whereby payment for the item is initiated if the first 
security code is validated. 

10. The system of claim 2, further comprising a cost 
discount storage for maintaining cost reduction information 
associated with a supplier's items, 

wherein the pricing means receives relevant parts of the 
cost reduction information to calculate the cost of the 
associated item, 

11. The system of claim 10, wherein the customer moni- 
toring object is configured to receive cost reduction infor- 
mation communicate the reduction information to the pric- 

25 ing means. 

12. The system of claim 11, wherein the customer moni- 
toring object is configured to confirm to the customer that 
the order for the item has been successfully processed 

13. The system of claim 12, wherein the supplier control 
30 means is configured to receive input, from a supplier at a first 

time, to define changes to the cost reduction information for 
a second time later than the first time. 

14. The system of claim U, further comprising supplier 
control means for receiving input, from a supplier, far 

35 changing the cost reduction information. 

15. The system of claim 2, further comprising means, 
responsive to an input from the customer, to terminate the 
customer* s interaction with the supplier whereupon which 
termination the customer monitoring object ceases to oper- 

40 ate. 

16. Hie system of claim 2, further comprising means, 
responsive to an input from the customer, to terminate the 
customer's interaction with the supplier whereupon the 
customer monitoring object ceases to operate and informa- 

45 tion regarding at least the interaction is stored for retrieval 
at a subsequent time at which the customer interacts with the 
supplier whereby the customer monitoring object recom- 
mences operation utilizing the stored information. 

17. The system of claim 16, wherein the participant 
50 program object includes information related to forms of 

payment available to the customer. 

18. The system of claim 2, further comprising means for 
accessing the customer information database and for creat- 
ing a participant program object including information spe- 

ss cine to the customer retrieved from the information database 
and in communication with and for passing customer spe- 
cific information the customer monitoring object. 

19. The system of claim IS, wherein the participant 
program object is created at the time an interaction between 

60 the customer and the system commences. 

20. The system of claim 2, further comprising an obser- 
vation subsystem for receiving and maintaining customer 
interaction information relating to at least one customer's 
communications over the computer driven network. 

65 21. Hie system of claim 20, further comprising supplier 
control means for receiving input, from a supplier, for 
changing the cost reduction information. 
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22. The system of claim 21, wherein the supplier control 
means is configured to receive input, from a supplier at a first 
time, to define changes to the cost reduction information for 
a second time later than the first time. 

23. The system of claim 22 wherein the supplier control 
means is in communication with the observation subsystem 
to receive customer interaction information for display to the 
supplier. 

24. The system of claim 23, wherein the supplier control 
includes: 

a. an information processor for processing received cus- 
tomer interaction information; and 

b. means for selectively displaying at least a part of the 
processed customer interaction information to the sup- 
plier. 

25. The system of claim 2 wherein die means for causing 
at least one supplier to be represented can cause a plurality 
of suppliersj o be represented, the system further comprising 
means to Enable a customer to select at least one of the 
represented suppliers. 

26. A system for facilitating commercial transactions, 
between a plurality of customers and at least one supplier of 
items, over a computer driven network capable of providing 
communications between the supplier and at least one 
customer site associated with each customer and including 
an input means and a display, the system comprising: 

a. means for causing at least one supplier to be repre- 
sented on the display for selection by the customer 
using the input means; 

b. means for effecting presentation of items on the display 
for customer observation; 

c. an item database associated with a supplier and includ- 
ing information on presented items; 

d. pricing means for receiving information from the item 
database to determine the cost associated with a pre- 
sented item; 

e. a customer information database for storing informa- 
tion relating to a customer; and 

f. means for creating a customer monitoring object for 
each customer by referencing information, relating to 40 
that customer, which had been stored in the customer 
information database and upon the customer selecting 

at least one supplier such that the customer monitoring 

object is configured to operate by 

i. responding to customer enquiries, communicated 45 
through the input means, regarding a presented item 
by accessing the item database to retrieve informa- 
tion relating to said item and to present said infor- 
mation to the customer by means of the display, 

iL receiving a customer's selection of a presented item 50 
through the input means, 

iii- communicating with the pricing means to have the 
cost of the item determined, 

iv. presenting the cost to the customer by means of the 
display, 

v. receiving customer communications, through the 
input means, indicating a desire to receive the item, 

vi. passing a delivery initiation communication to ini- 
tiate the delivery of the item to the customer; and 

g. a means for accessing the customer information data- 
base and for creating a participant program object 
including information specific to the customer retrieved 
from the information database and in communication 
with and for passing customer specific information to 
the customer monitoring object 

27. The system of claim 26, further comprising a customer 
monitoring object configured to operate by: 
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a. responding to customer enquiries, communicated 
through the input means, regarding a presented item by 
accessing the item database to retrieve information 
relating to said item and to present said information to 
the customer by means of the display, 

b. receiving a customer's selection of a presented item 
through the input means, 

c. communicating with the pricing means to have the cost 
of the item determined, 

<L presenting the cost to the customer by means of the 
display, 

e. receiving customer communications, through the input 
means, indicating a desire to receive the item, 

f. passing a delivery initiation communication to initiate 
the delivery of the item to the customer, and 

g. maintaining a list of selected items and present the 
customer with a cost of the selected items for approval 
by the customer before the customer monitoring object 
passes the delivery initiation communication. 

28. The system of claim 27, wherein the customer moni- 
toring object is configured to present the customer with an 
opportunity to deselect an item whereupon the customer 
monitoring object communicates with the pricing means to 
have the costs of the renaming selected items redetermined 
and presented anew to the customer. 

29. The system of claim 27, further comprising order 
fulfillment initiation means, responsive to the delivery ini- 
tiation communication from the customer monitoring object, 
for initiating proceedings to cause the item desired by the 
customer delivered to the customer. 

30. The system of claim 27, wherein the order fulfillment 
means includes an interface with a shipping facility for 
facilitating the shipping of the desired item to the customer. 

31. The system of claim 27, further comprising a payment 
handier means for initiating customer payment for the 
desired item. 

31 The system of claim 31, wherein the payment handler 
means is responsive to communications from the customer 
monitoring object and receives information from the cus- 
tomer identification database in order to initiate customer 
payment 

33. The system of claim 27, further comprising a payment 
validation system including 

means for causing the customer monitoring object to 
receive the information related to the forms of payment 
available to the customer and to present the customer 
with a selection of the forms of payment; 

means for receiving a first security code, related to a 
selected form of payment, from the customer; and 

means for validating the first security code by comparison 
to a second security code available to the customer 
monitoring object; 

whereby payment for the item is initiated if die first 
security code is validated. 

34. The system of claim 27, further comprising a cost 
discount storage for maintaining cost reduction information 
associated with a supplier's items, 

wherein the pricing means receives relevant parts of the 
cost reduction information to calculate the cost of the 
associated item 

35. The system of claim 34, wherein the customer moni- 
toring object is configured to receive cost reduction infor- 
mation communicate the reduction information to the pric- 
ing means. 

36. The system of claim 35, further comprising means for 
receiving input, from a supplier, for changing the cost 
reduction information. 
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37. The system of claim 36, wherein the supplier control 
means is configured to receive input, from a supplier at a first 
time, to define changes to the cost reduction information for 
a second time later than the first time. 

38. The system of claim 27, further comprising means, 
responsive to an input from the customer, to terminate the 
customer's interaction with the supplier upon which termi- 
nation the customer monitoring object ceases to operate. 

39. The system of claim 27, further comprising means, 
responsive to an input from the customer, to terminate the 
customer's interaction with the supplier whereupon the 
customer monitoring object ceases to operate and informa- 
tion regarding at least the interaction is stored for retrieval 
at a subsequent time at which the customer interacts with the 
supplier whereby the customer monitoring object recom- 
mences operation utilizing the stored information. 

40. The system of claim 27, wherein the participant 
program object is created at the time an interaction between 
the customer and the system commences. 

41. The system of claim 40, wherein the participant 
program object includes information related to forms of 
payment available to the customer. 

42. The system of claim 27, further comprising means for 
causing at least one supplier to be represented on the display 
and means for receiving an input from the customer indi- 
cating a selection of a represented supplier. 

43. The system of claim 42, whereby said means for 
creating a customer monitoring object creates the customer 
monitoring object for the customer when the customer 
selects the supplier. 
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44. The system of claim 27, further comprising an obser- 
vation subsystem for receiving and maintaining customer 
interaction information relating to at least one customer's 
communications over the computer driven network. 
5 45. The system of claim 44, further comprising supplier 
control means for receiving input, from a supplier, for 
changing the cost reduction information. 

46. The system of claim 45, wherein the supplier control 
means is configured to receive input, from a supplier at a first 

10 time, to define changes to the cost reduction information for 
a second time later than the first time. 

47. The system of claim 46, wherein the supplier control 
means is in communication with the observation subsystem 

1 3 to receive customer interaction information for display to the 
supplier. 

48. The system of claim 47, wherein the supplier control 
means includes: 

a. an information processor for processing received cus- 
20 tamer interaction information; and 

b. means for selectively displaying at least a part of the 
processed customer interaction information to the sup- 
plier. 

49. The system of claim 26 wherein the means for causing 
25 at least one supplier to be represented can cause a plurality 

of suppliers to be represented, the system further comprising 
means to enable a customer to select at least one of the 
represented suppliers. 

* * * * * 
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